Gemini usually drops the malformed call upstream, so the final chunk
carries only the finishReason and the started-calls guard never fired.
The turn surfaced as a clean empty completion instead of an error.
MAX_TOKENS with no started call keeps its plain token-limit stop.

(cherry picked from commit 6eb5903)

The streaming translator folded every summary part into one thinking
block with no separator, so multi-part summaries rendered as run-on
text. The JSON path already joins parts with a blank line; the stream
now emits the same separator at part boundaries.

(cherry picked from commit b23cc1f)

The native branch buffers the upstream compact JSON and returns it
without inspecting the body, so the request log row lands with no
usage. Lift usage and response metadata from the buffered body the
same way the routed branch gets it through handleResponses.

(cherry picked from commit 2ae3b5f)

(cherry picked from commit 88d60c3)

Kiro never returns plaintext reasoning for its Sol-family models. Its
`reasoningContentEvent` carries a KMS-encrypted `redactedContent` blob, and
`gpt-5.6-sol`'s `additionalModelRequestFieldsSchema` accepts only
`reasoning.effort` — there is no display or summary opt-in. Kiro's own CLI
replays that blob on the matching `assistantResponseMessage.reasoningContent`
to preserve model reasoning across turns.

The adapter read only `reasoningContentEvent.text`, which is absent on this
wire, so the blob was dropped and never replayed. Every turn therefore
restarted without the previous turn's reasoning.

- kiro-events: parse `redactedContent`; add the previously unhandled
  `contextUsageEvent` (Kiro reports context pressure there, not in
  `metadataEvent`, which carries only `stopReason`).
- Carry the blob through the existing `ocxr1:` envelope as `krc` on an
  envelope-only reasoning item, so it round-trips while staying invisible in
  the app — the same contract the hidden-thinking path already uses.
- Pair it backwards: Kiro emits the event at the END of a turn, after content
  and tool calls, so a krc-only item belongs to the assistant turn that already
  closed. Folding it forward would attach turn N's blob to turn N+1. With no
  assistant turn to own it, the blob is dropped rather than mis-paired.
- Replay it on `assistantResponseMessage.reasoningContent`.

Verified against kiro-cli 2.14.1 and 2.16.0 request/response captures.

(cherry picked from commit cbb5d21)

CodeRabbit caught a real defect that made the round-trip a no-op in the
streaming path.

Kiro sends its reasoning blob at the END of a turn, while the assistant message
is still open. Emitting the envelope-only item on arrival was wrong twice over:

- `outputIndex` only advances when an item CLOSES, so the open message and the
  envelope item were emitted under the same output index.
- The envelope landed BEFORE the assistant message, and the parser pairs a
  krc-only item backwards, so it found no preceding assistant turn and dropped
  the blob as orphaned — silently defeating the fix.

Both paths now stash the blob and flush it after every open item has closed:
after the closes in the streaming `done` case, and after the trailing flushes in
the batch path. Message phase inference is untouched, so a Kiro final answer is
still classified `final_answer` rather than being force-closed as commentary.

The batch path also released `bytesOf(encrypted)` through `pushOutput` without
ever retaining it. It now charges the blob when stashing and lets `pushOutput`
release that retained allocation, so the translator budget balances.

Adds tests/kiro-reasoning-roundtrip.test.ts, which bridges adapter events and
re-parses the emitted items the way Codex replays history — the end-to-end
coverage the original tests lacked. Three of its five cases fail against the
previous commit.

Scope: verified that gpt-5.6-terra and gpt-5.6-luna return `redactedContent`
exactly like gpt-5.6-sol, so the whole GPT-5.6 family was affected. Handling
keys off the wire field, not the model id.

(cherry picked from commit bd13d48)

…blob

The batch budget assertion was vacuous twice over. It passed the budget in the
wrong argument position, so `buildResponseJSON` built its own internal budget and
the snapshot under test was never written to (`highWaterBytes: 0`). Even wired
correctly, asserting `currentBytes >= 0` could not distinguish a leaked raw blob
from the finalized items that legitimately stay retained.

It now uses a 4 KB blob and asserts `currentBytes` equals EXACTLY the finalized
output items' bytes — a still-retained raw blob shows up as ~4 KB of excess, and
releasing bytes that were never charged shows up as a shortfall. A separate
`highWaterBytes` assertion proves the blob was charged while held rather than
never accounted for. Four of the file's five cases now fail against cbb5d21.

Also corrects the metadataEvent description: every capture put the context
percentage in `contextUsageEvent`, but the parser still accepts a finite
`contextUsagePercentage` (and `tokenUsage`) from `metadataEvent` as a fallback,
so documenting it as impossible was wrong.

(cherry picked from commit 8610630)